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1 Executive Summary 


This document outlines the security review conducted by Nethermind for the LayerAkira on-chain settlement layer. LayerAkira is a hybrid 
central limit orderbook protocol where users can submit signed orders to an off-chain orderbook which will match and execute trades 
through the LayerAkira Cairo contracts. Liquidity can be sourced from orders submitted by users, or routers, which are entities that allow 
funds to be sourced from other means outside of the LayerAkira ecosystem. 


The audited code comprises 3210 lines of code. The LayerAkira team has provided comprehensive documentation explaining the 
behavior of protocol and the reviewed smart contracts. Aside from the provided documentation, the LayerAkira and Nethermind Security 
teams have communicated to clarify any remaining questions about the expected behavior of the protocol. 


The audit was performed using (a) manual analysis of the codebase, (b) automated analysis tools, (c) simulation of the smart contract. 
Along with this document, we report 12 points of attention, where one is classified as Medium, three are classified as Low, four are classified 
as Info and four are classified as Best Practices. The issues are summarized in Fig. 1. 


This document is organized as follows. Section 2 presents the files in the scope of this audit. Section 3 summarizes the issues. 
Section 4 describes the system overview. Section 5 discusses the risk rating methodology adopted for this audit. Section 6 details 
the issues. Section 7 discusses the documentation provided by the client for this audit. Section 8 presents the compilation, tests, and 
automated tests. Section 9 concludes the document. 


Severity Status 


Medium Mitigated 


Best Practices 


Info 


(а) (b) 


Fig. 1: Distribution of issues: Critical (0), High (0), Medium (1), Low (3), Undetermined (0), Informational (4), Best Practices (4). 
Distribution of status: Fixed (11), Acknowledged (0), Mitigated (1), Unresolved (0), Partially Fixed (0) 


Summary of the Audit 
Audit Type Security Review 
Initial Report June 21, 2024 
Response from Client June 21, 2024 
Final Report June 28, 2024 
Repository LayerAkira/kurosawa akira 
Commit (Audit) f1cb9acbd363e16e36095ee132770ecdb726a885 
Commit (Final) 94e206a70595e10428486449bca9b4432d9c5d16 
Documentation Assessment High 
Test Suite Assessment High 
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Contract LoC Comments | Ratio Blank Total 
1 src/ILayerAkira.cairo 126 16 12.796 49 191 
2 src/FundsTraits.cairo 16 11 68.896 4 31 
3 src/lib.cairo 15 0 0.0% 0 15 
4 src/WithdrawComponent.cairo 188 21 11.296 47 256 
5 src/NonceComponent.cairo 139 2 1.496 19 160 
6 src/EcosystemTradeComponent.cairo 888 26 2.996 70 984 
7 src/ExchangeBalanceComponent.cairo 283 3 1.196 30 316 
8 src/SignerComponent.cairo 90 7 7.896 13 110 
9 src/DepositComponent.cairo 77 3 3.9% 12 92 
10 src/RouterComponent.cairo 332 38 11.4% 45 415 
11 src/LayerAkira.cairo 457 2 0.4% 42 501 
12 src/Order.cairo 300 7 2.3% 31 338 
13 src/signature.cairo 3 0 0.0% 0 3 
14 src/utils.cairo 4 0 0.0% 0 4 
15 src/utils/erc20.cairo 21 2 9.596 1 24 
16 src/utils/common.cairo 17 0 0.0% 2 19 
17 src/utils/account.cairo 17 0 0.096 1 18 
18 src/utils/SlowModeLogic.cairo 6 0 0.0% 1 7 
19 src/signature/V0OffchainMessage.cairo 55 3 5.596 6 64 
20 src/signature/AkiraV0OffchainMessage.cairo 158 12 7.696 16 186 
21 src/signature/IOffchainMessage.cairo 18 0 0.0% 4 22 
Total 3210 153 4.896 393 3756 
3 Summary of Issues 
Finding Severity Update 
1 User may not be able to apply on-chain withdrawals Medium Fixed 
2 Receiver address for withdrawals is never checked Low Fixed 
3 Router punishment can be abused to extract unclaimed router fees Low Fixed 
4 fee recipient address can be set to zero address Low Fixed 
5 Missing validation could lead to deny new exchange version Info Fixed 
6 Good After Time (GAT) orders can be filled before their valid date Info Mitigated 
7 Tautology in the . transfer function Info Fixed 
8 The . do. part external taker. validate function validates taker order's nonce with itself | Info Fixed 
9 Function/variable/comment corrections Best Practices Fixed 
10 Inconsistency in error message Best Practices Fixed 
11 Redundant checking in the function do maker checks Best Practices Fixed 
12 bind. to. signer does not check signer address Best Practices Fixed 
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4 System Overview 


LayerAkira Contract: Fig. 2 presents the component diagram for the LayerAkira on-chain settlement layer. The LayerAkira block (in 
yellow) represents the contract LayerAkira where all other components (in blue color) are imported. Admin only functionality such as 
the managment of versions, routers, whitelisted invokers, and the fee recipient is handled here. All other relevant functions from the 
components illustrated on the diagram are publicly exposed to whitelisted invokers and users through this contract. 
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Fig. 2: Component diagram of the audited contracts 


4.1 LayerAkira Components 


Functions and Structs: There are several cairo files that contain structs and functions used by components. For example, the Order 
consists of several structs to organize data related to orders and functions to validate taker and maker orders. 


DepositComponent: Allows users to directly deposit to the contract, where their funds can be used to create and sign orders to be 
submitted to the orderbook. This component relies on the ExchangeBalanceComponent to update balances upon a successful deposit. 


EcosystemTradeComponent: Contains the majority of logic related to validation and settlement of matched orders. Two order match 
functions apply ecosystem trades and apply. single taker are exposed by the LayerAkira contract allowing whitelisted invokers to exe- 
cute orders. The punishment mechanism for routers which sign trades that are unexecutable is also handled within this component. 


ExchangeBalanceComponent: Tracks user deposits and (partial) router balances as deposits and withdrawals occur. Additional func- 
tions exist to support gas payments to compensate for whitelisted invoker execution costs as well as balance adjustments after orders 
have been matched and executed. 


NonceComponent: Handles nonces for users, with an public function allowing users to increase their nonce. These nonces are part of 
the order data, and are validated during execution to ensure that the nonce is not lower than the current. This allows users to invalidate all 
their existing orders if necessary. 


RouterComponent: Logic for management of routers, which connects LayerAkira to external sources of liquidity. It contains functions for 
router registration, deposits, withdrawals and signer binding. Routers can also be de-registered with a delay, where they must first request 
and then apply. 


SignerComponent: Contains logic for verifying that signatures are valid, as well as allowing traders to bind a signer address to their own 
address, meaning that signatures can be verified with a different address from the one that recieves funds. 


WithdrawComponent: Mechanism for allowing users to withdraw funds in two different ways. The first approach is to have a whitelisted 
invoker execute the withdrawal. This will occur immediately and funds are sent to the recipient with no time delay. A user is also able to 
initiate a withdrawal of their funds at any time, with a certain delay. This delay gives the off-chain orderbook a grace period to react to any 
existing orders that may rely on the liquidity about to be removed. 
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5 Risk Rating Methodology 


The risk rating methodology used by Nethermind follows the principles established by the OWASP Foundation. The severity of each finding 
is determined by two factors: Likelihood and Impact. 


Likelihood measures how likely the finding is to be uncovered and exploited by an attacker. This factor will be one of the following values: 
a) High: The issue is trivial to exploit and has no specific conditions that need to be met; 
b) Medium: The issue is moderately complex and may have some conditions that need to be met; 
C) Low: The issue is very complex and requires very specific conditions to be met. 


When defining the likelihood of a finding, other factors are also considered. These can include but are not limited to motive, opportunity, 
exploit accessibility, ease of discovery, and ease of exploit. 


Impact is a measure of the damage that may be caused if an attacker exploits the finding. This factor will be one of the following values: 
a) High: The issue can cause significant damage, such as loss of funds or the protocol entering an unrecoverable state; 


b) Medium: The issue can cause moderate damage, such as impacts that only affect a small group of users or only a particular part 
of the protocol; 


C) Low: The issue can cause little to no damage, such as bugs that are easily recoverable or cause unexpected interactions that 
cause minor inconveniences. 


When defining the impact of a finding, other factors are also considered. These can include but are not limited to Data/state integrity, loss 
of availability, financial loss, and reputation damage. After defining the likelihood and impact of an issue, the severity can be determined 
according to the table below. 


Severity Risk 
High Medium High Critical 
Impact Medium Low | Medium High 
Low Info/Best Practices | Low Medium 
Undetermined Undetermined Undetermined Undetermined 
Low Medium High 
Likelihood 


To address issues that do not fit a High/Medium/Low severity, Nethermind also uses three more finding severities: Informational, Best 
Practices, and Undetermined. 


a) Informational findings do not pose any risk to the application, but they carry some information that the audit team intends to pass 
to the client formally; 


b) Best Practice findings are used when some piece of code does not conform with smart contract development best practices; 


c) Undetermined findings are used when we cannot predict the impact or likelihood of the issue. 
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6 Issues 


6.1 [Medium] User may not be able to apply on-chain withdrawals 


File(s): src/WithdrawComponent.cairo 


Description: The user can apply off-chain and on-chain withdrawals. When users call the request. onchain withdraw function, it creates 
a pending withdrawal request for a particular token. Later, they need to invoke the apply. onchain. withdraw function to complete the 
ongoing request. On the other hand, they can withdraw by validating their signature. This issue emerges according to the order of calls, 
for example: 


1. Alice calls request. onchain withdraw to request an on-chain withdrawal of 100 A. Then, the function creates a pending request in 
pending reqs for token A. 


let key - (withdraw.token, withdraw.maker); 
self .pending_reqs.write(key, (SlowModeDelay (block:get block number(), ts: get block timestamp()), withdraw)); 


2. Alice decides not to wait the minimum period to apply the on-chain withdrawal through the apply onchain withdraw and executes the 
off-chain withdrawal of 100 tokens A by validating her signature. 


3. Later, she wants to execute an on-chain withdrawal of 50 for A. She needs to create a new request because the pending one is with 
100 tokens A. The request. onchain. withdraw function checks whether the previous pending request is completed, thus reverting the 
transaction. 


fn request onchain withdraw(ref self: ComponentState<TContractState>, withdraw: Withdraw) { 
ЖАКЕ 
let (pending ts, w prev): (SlowModeDelay, Withdraw) = self.pending reqs.read(key); 
let w hash - withdraw.get message hash(withdraw.maker); 


assert!(w prev !- withdraw, "ALREADY REQUESTED: withdraw for this token already requested"); 
// @audit it will revert when checking if the request is completed. 


If The hash for w prev can be different from withdraw 

// because we have several attributes in the 

// Withdraw struct. Particularly, the values in the gas_fee 

// struct tend to change 

assert! (w_prev.amount == 0 || self.completed_reqs.read(w_prev.get_message_hash(w_prev.maker)), 
^ "NOT. YET. COMPLETED. PREV: previous withdraw has not been completed yet"); 

Il as 


Then, Alice is forced to withdraw 100 tokens A (that she has already withdrawn) if she wants to continue to use the on-chain withdraw 
method. Otherwise, she will be able to execute only off-chain withdrawals. We can extend this example to millions of tokens A where 
the user may not be able/interested to complete the pending request. 


Recommendation(s): Consider applying the same mechanism used for requesting and applying onchain unregister routers. For example: 


— Set block and ts to zero when user calls in the apply. withdraw function: ; 


fn apply. withdraw(ref self: ComponentState<TContractState>, signed withdraw: SignedWithdraw, gas. price:u256, 
>  CUF. gas, per. action:u32) { 

77 

*let key - (signed withdraw.withdraw.token, signed withdraw.withdraw.maker); 

-let (delay, w_req):(SlowModeDelay, Withdraw) = self.pending_reqs.read((signed_withdraw.withdraw. token, 

+ signed withdraw.withdraw.maker)); 

*let (delay, w_req):(SlowModeDelay, Withdraw) = self.pending reqs.read(key); 


assert!(!self.completed reqs.read(hash), "ALREADY, COMPLETED: withdraw (hash = ())", hash); 


// @audit clear the pending reqs 

*self.pending reqs.write(key, SlowModeDelay(block:0,ts:0j); 
LP. ss 

J 


— Apply a checking in the request. onchain. withdraw function to ensure that there is no ongoing pending request for withdrawal: ; 


let (pending ts, w prev): (SlowModeDelay, Withdraw) = self.pending reqs.read(key);" 
*assert!(pending ts.block == 0, "ONCHAIN. WITHDRAW, ALREADY. REQUESTED: ..."); 
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Status: Fixed 


Update from the client: In this circumstance, the user may fix this issue by depositing funds back and fixing the pending withdrawal. As 
the Exchange does not charge a withdrawal fee, the User will only be losing out on gas in this scenario. 


For a better user experience, the logic for apply withdraw has been adjusted to invalidate any pending withdrawal if the user applies a 
withdrawal that is different from the scheduled one. This change will also apply if user wishes to invalidate their pending withdrawal. 


See pull request #25 in commit: 94e206a70595e10428486449bca9b4432d9c5d16 


6.2 [Low] Receiver address for withdrawals is never checked 
File(s): src/WithdrawComponent.cairo 


Description: The on-chain withdrawal relies on pending requests that the user needs to create before withdrawing. However, the 
request. onchain. withdraw function does not verify the receiver address where the tokens will be transferred to. 


fn request, onchain withdraw(ref self: ComponentState<TContractState>, withdraw: Withdraw) { 


// @audit check if withdraw.receiver is not address zero. This validation is not applied in this function. 
assert!(get caller address() == withdraw.maker, "WRONG MAKER: withdraw maker ({}) should be equal caller (())", 
> withdraw.maker, get caller address()); 

assert!(withdraw.amount > 0, "WITHDRAW CANT BE ZERO"); 


TE жез 
assert!(w prev !- withdraw, "ALREADY REQUESTED: withdraw for this token already requested"); 
assert!(w prev.amount == 0 || self.completed reqs.read(w. prev.get. message hash(w. prev.maker)), 


"NOT. YET. COMPLETED. PREV: previous withdraw has not been completed yet"); 


assert!(!self.completed reqs.read(w hash), "ALREADY COMPLETED: requested withdraw has already been completed"); 
E wes 


When the caller invokes apply. onchain. withdraw, the function gets the pending request created for the particular token by request. - 
onchain. withdraw 


fn apply.onchain. withdraw(ref self: ComponentState<TContractState>, token:ContractAddress, key:felt252) { 
let caller = get caller address); 
let (delay, w req): (SlowModeDelay,Withdraw) - self.pending reqs.read((token, caller)); 
H egs 
self. transfer(w req, key, w req.amount, 0, true); 


Once the user requests an on-chain withdraw, the receiver can not be changed and the apply. onchain, withdraw function reverts since 
the function ERC20. transfer reverts when receiver is zero address. 


fn transfer(ref self: ComponentState<TContractState>, w req:Withdraw, w hash:felt252, tfer amount:u256, 
^ gas price:u256, direct:bool) { 

rA 

erc20.transfer(w req.receiver, tfer amount); 

TE жез 


Recommendation(s): Validate the receiver address in request. onchain withdraw. 
Status: Fixed 


Update from the client: Added suggested asserts in pull request #25 in commit 94e206a70595e10428486449bca9b4432d9c5d16 


(7) SECURITY 


6.3 [Low] Router punishment can be abused to extract unclaimed router fees 


File(s): src/EcosystemTradeComponent.cairo 


Description: When an order is matched that uses external funds, a router must sign the order, and it should not fail during execution 
otherwise the router will be punished. The punishment is a percentage of the charged fee that the order would have cost to execute 
multiplied by two, and then split between the protocol fee recipient address and the maker order address. 


fn punish, router. simple(...) { 
d nsus 
// Punishment is a percentage of the gas cost 
let charged fee = gas. fee.gas. per. action.into() 
х gas px 
* router.get punishment factor bips().into() 
/ 10000; 
if charged fee == 0 ( return; } 
// Router loses 2x the charged fee 
// One half goes to protocol, other half goes to maker order address 
router.burn(router_addr, native base token, 2 х charged fee); 
balancer.mint(balancer.fee recipient.read(), charged fee, native base token); 
balancer.mint(maker, charged fee, native base token); 
IT- ss 


As part of the calculation for charged. fee the gas price is multiplied by the gas per action. The gas. px argument is provided by the caller 
which is a trusted whitelisted invoker address, however the gas. per. action is provided from the gas. fee field from the taker order's data. 
This allows a taker to arbitrarily control the punishment fee that a router would incur if execution of an order failed. 


To avoid punishments, the router is expected to verify that the taker's order is valid by simulating it's execution. A taker can construct 
a custom smart wallet implementation that will return a valid signature on simulation, but fail during execution. This can be done by 
inspecting the get. tx info().unbox().version field and checking for the "simulate" bit at position 128. Another approach could be to 
simply use a regular contract instead, where the function is. valid signature can access state and arbitrarily return whether a signature 
is valid or not. 


Since the punishment fee imposed on the router is split between the protocol and the maker order, an attacker can construct a maker 
order and a taker order that will immediately match with each other. The taker order would have a gas. fee.gas. per. action which is set 
to a value such that after it is multiplied with the current gas. px, adjusted by the punishment factor and multiplied by two, is equal (or very 
close to) the balance of the router address. When the punishment is applied, the attacker will receive half of the unclaimed fees belonging 
to the router since the maker order also belongs to them. 


This finding relies on offchain components to behave a certain way to be feasible. The router must accept user order data rather than 
generating data and submitting it to the user to sign. The router also should miss validity checks on the gas steps field. Validations on the 
expected execution cost would need to check for profit after execution, with no upper bounds (if user offers excessive gas payment it would 
accept). In order to profit from this attack, an attacker must match their own taker and maker order, which may be challenging depending 
on factors such as spread and volatility. If the attacker's taker order matches with another user's maker order, they will receive the stolen 
funds instead. 


In summary, an attacker can construct self-matching maker/taker orders and manipulate their gas. per. action field with a specific value 
that will result in the punishment fee being equal to a router's unclaimed fee balance. The attacker can guarantee that punishment will 
occur by using a custom wallet implementation, and when the punishment is applied they will receive half of the router's unclaimed fees. 


Recommendation(s): Consider adjusting the punish. router. simple function to use the cur. gas. per. action argument provided by the 
whitelisted invoker inapply. single. taker, instead of using the untrusted gas. per. action provided by the taker order. This will prevent the 
punishment fee from being controlled by the taker order. 


Status: Fixed 
Update from the client: 
This issue relates only to the unclaimed portion of fees the Router earns through orders routed to LayerAkira. 


The likelihood of these fees getting drained is highly unlikely and would only arise in a scenario where the maker, taker and exchange all 
act negligently / maliciously. This is because: 


— LayerAkira will be applying the rollups on the exchange and will require users to use a specific value for gas per. action since we 
know the upper bound of what the user would spend ; 


— |f more trades can fit into a rollup, then the Exchagne will adjust the steps per user, making it cheaper per user. The point here is 
that this is a constant field; 


— The Taker cannot perform this attack as the Exchange will be doing checks and marking these types of orders as invalid ; 


— The risk is further mitigated when the Router performs basic checks on the Taker, which is what the Router receives its portion of 
the Router Rewards for (and therefore is in its best interest to do); 


The suggested asserts have also been implemented to make this scenario even more unlikely in pull request #25 commit 
de4853abe8e3ff9a6d75ca3b38db20af 757b9f6d. 
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6.4 [Low]fee recipient address can be set to zero address 
File(s): src/LayerAkira 


Description: The owner calls update_fee_recipient to update the fee recipient address. The fee_recipient receives tokens from the 
users when they pay fees. However, the owner could set a zero address by mistake since the function does not check the new_fee_- 
recipient value. The owner can easily fix this issue, but the protocol may lose tokens until the problem is detected. 


#[external (v@) ] 
fn update_fee_recipient(ref self: ContractState, new_fee_recipient: ContractAddress) { 
assert! (self.owner.read() == get caller address(), "Access denied: update fee recipient is only for the owner's 
э use"); 
// @audit fee recipient should always be different from zero 
// since fees are transferred to this address 
self.balancer. s.fee recipient.write(new fee recipient); 
self.emit(FeeRecipientUpdate(new. fee recipient)); 


Recommendation(s): Consider adding a check if new. fee. recipient is not zero address. 
Status: Fixed 


Update from the client: We have addressed the recommendation in pull request #25 in commit 94e206a70595e10428486449bca9b4432d9c5d16 


6.5 [Info] Missing validation could lead to deny new exchange version 
File(s): src/LayerAkira.cairo 


Description: Before filling orders, generic taker check(...) validates if maker and taker are using the same exchange version and to 
update the contract's version, only versions higher than the current one are allowed: 


fn update exchange version(... , new version:u16) ( 
// @audit Condition to enforce version incrementation 
assert! (new, version > self.exchange version.read(), "Exchange version can only increase"); 
I s 


The problem is that in case of malicious or unintentional upgrade to u16 maximum value the contract won't admit new exchange versions. 


Recommendation(s): Add a validation in update. exchange. version to restrict the difference between the current and new version num- 
bers. 


Status: Fixed 


Update from the client: Addressed in pull request #25 commit f4ee3230a2c99b22398de5027bcd4adcad804fb4. The field has been removed 
as it no longer has any business logic behind it. The signature logic was adjusted to factor in the account contract address. This will avoid 
replicating fills of orders that users submit for the original exchange. Users can be assured that the orders they sign are only valid on the 
particular version of the exchange. 
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6.6 [Info] Good After Time (GAT) orders can be filled before their valid date 


File(s): src/Order.cairo 


Description: A good-after-time (GAT) order is a trading instruction which can be combined with market orders, limit orders and other order 
types. A GAT order instructs to wait until a predetermined time or date has transpired before order become valid. 


To create an order, market participants specify creation and duration timestamps that define the time period in which the order is considered 
valid and can be filled by takers. The timestamps are validated in do. maker. checks(...) and generic taker check(...) functions as 
part of the order fulfilment process. The problem is that these functions lack checks to determine if the current timestamp is greater than 
the created. at attribute of the order. 


fn do maker, checks(...) { 
I uds 
// @audit This condition just validates the end of valid time. 
assert!(get block timestamp() < maker_order.constraints.created_at.into() + 
^ maker_order.constraints.duration_valid.into(), "Maker order expire (j" 
— maker order.constraints.duration valid); 
VE os 


fn generic taker check(...) { 
ЙЛ 3s 
// @audit This condition just validates the end of valid time. 
assert!(get block timestamp() <  taker order.constraints.created at.into() + 
^  taker order.constraints.duration valid.into(), "Taker order expire (j" 
^  taker order.constraints.duration valid); 


Recommendation(s): Before filling the order, consider validating that the timestamp is greater or equal to the order creation timestamp. 
Status: Mitigated 


Update from the client: This issue is addressed with the Exchange's off-chain validation logic. When orders are sent to the Exchange, 
orders created too early are marked as stale and therefore not processed. This check was moved off-chain so that it does not present 
friction when the Exchange is performing rollups. 


6.7 [Info] Tautology in the . transfer function 


File(s): src/WithdrawComponent.cairo 


Description: The function transfer is called during withdrawals. This function receives the boolean parameter direct. 


fn transfer(ref self: ComponentState<TContractState>, 
w_req:Withdraw, 
w_hash: felt252, 
tfer_amount:u256, 
gas_price:u256, 
direct:bool) ( 
Eb sss 


The apply. withdraw function calls . transfer, passing the value of the comparison of w req == signed withdraw.withdraw. As presented 
below, it invokes . transfer, w req always equal to signed. withdraw.withdraw. 


fn apply_withdraw(ref self: ComponentState<TContractState>, signed withdraw: SignedWithdraw, gas price:u256, 
— cur. gas. per. action:u32) ( 

let hash = signed. withdraw.withdraw.get message hash(signed withdraw.withdraw.maker); 

let (delay, w_req):(SlowModeDelay, Withdraw) = self.pending reqs.read((signed withdraw.withdraw.token, 

^ Signed withdraw.withdraw.maker)); 

ДИО 

// (audit w_req is now equal to signed withdraw.withdraw 

let w. reg = signed withdraw.withdraw; 


ДАШУУ, 
// @audit-info Tautology: the result of w req == signed. withdraw.withdraw is always true 
self. transfer(w req, hash, tfer amount, gas price, w req -- signed withdraw.withdraw); 


10 
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Similarly, the apply. onchain withdraw function always passes true to _transfer. 


fn apply. onchain.withdraw(ref self: ComponentState<TContractState>, token:ContractAddress, key:felt252) { 
VT vs 
self. transfer(w req, key, w req.amount, 0, true); 


Recommendation(s): Consider removing this parameter or reevaluating the goal for the direct parameter. 
Status: Fixed 


Update from the client: The apply. onchain. withdraw function always passes true to . transfer because this flag in the event indicates 
the origin of the withdrawal, whether it is generated off-chain or on-chain. Since apply onchain withdraw is on-chain, the flag is always 
set to true. 


In contrast, when the exchange performs a rollup with user withdrawals, the exchange need to distinguish whether it is the finalization of 
an on-chain withdrawal or purely an off-chain one. This has now been addressed by performing this comparison before reassigning w. req 
to signed. withdraw.withdraw. 


Addressed in pull request #25 in commit 94e206a70595e10428486449bca9b4432d9c5d16 


6.8 [Info] The do. part. external, taker. validate function validates taker order's nonce 
with itself 


File(s): src/EcosystemTradeComponent.cairo 


Description: The function apply. single taker invokes . do. part external taker. validate when the taker order defines that the source 
of the funds to execute the trade are not from the balance of the Exchange, i.e., it is flagged external funds-true. As presented below, 
- do. part. external. taker. validate calls generic taker. check function to validate data related to taker orders. 


fn |. do. part, external taker, validate(self:GComponentState«TContractState»^, 

signed taker order:SignedOrder, swaps:u16, version: u16, fee recipient:ContractAddress) -> 
^ (Order,felt252,0rderTradeInfo, u256) { 

УЙ es 

// @audit the taker order's nonce is passed instead the one in NonceComponent.get nonce(taker, order.maker) 
super: :generic_taker_check(taker_order, taker fill info, taker order.constraints.nonce, swaps, taker hash, 
^ version, fee recipient); 

LE teas 


The generic_taker_check function receives several information associated to the taker order, such as the taker_order and the nonce of 
the current order (instead get from NonceComponent.get. nonce(taker. order.maker). Then, the function checks whether the taker orders’ 
nonce is greater than or equal to nonce. This checking will be always true, since the nonce parameter represents the nonce assigned in 
the taker order. 


fn generic_taker_check(taker_order:Order, taker fill info:OrderTradeInfo, nonce:u32, swaps:ul6, 
=  taker order hash:felt252, version:u16, fee recipient:ContractAddress) ( 

UD ss 

assert!(taker order.constraints.nonce »- nonce, "OLD TAKER NONCE"); 

M ws 


This error does not trigger any vulnerability because the taker's nonce is correctly implemented іп the . prepare. router. taker function 
that is called later by apply single taker. However, . do. part. external taker validate may be reused somewhere in future changes 
and it could add issues. 


Recommendation(s): Consider applying the following change: 


-super::generic, taker. check(taker order, taker fill info, taker order.constraints.nonce, swaps, taker hash, version, 
^ fee recipient); 

*super::generic, taker  check(taker order, taker fill info, contract.get nonce(taker order.maker), swaps, taker hash, 
^ version, fee recipient); 


Status: Fixed 
Update from the client: Addressed in pull request #25 in commit de4853abe8e3ff9a6d75ca3b38db20af 757b9f6d. 
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6.9 [Best Practice] Inconsistency in error message 


File(s): src/LayerAkira.cairo 


Description: The owner invokes update. exchange. version to update the exchange version. When the caller is not the owner, it triggers 
an error message of access denied to the update. exchange. invorkers function instead of update. exchange. version. 


#[Lexternal(v@) ] 
fn update_exchange_version(ref self: ContractState, new, version:u16) { 
// @audit the error message is referring to update_exchange_invokers function 
assert! (self.owner.read() == get_caller_address(), "Access denied: update_exchange_invokers is only for the owner's 
+ use”); 
assert! (new, version > self.exchange version.read(), "Exchange version can only increase"); 
self.exchange version.write(new version); 
self.emit(VersionUpdate(new, version)); 


Recommendation(s): Consider adapting the error message to the proper function. 
Status: Fixed 


Update from the client: Adapted the error message to the properly function in pull request #25 in commit 94e206a70595e10428486449bca9b4432d9c5d16 


6.10 [Best Practice] bind to signer does not check signer address 
File(s): src/SignerComponent.cairo 


Description: The caller invokes bind. to. signer function to set a signer. The function checks if the signer is already set, updates the 
storage, and emits an event with the trader account and signer. However, it does not check whether signer is different from zero address. 


fn bind to signer(ref self: ComponentState<TContractState>, signer: ContractAddress) ( 
let caller - get caller address(); 
// @audit check if signer is not zero address 
assert! (self.trader_to_signer.read(caller) == 0.try into().unwrap(), "ALREADY BINDED: signer = {}” 
^ self.trader_to_signer.read(caller)); 
self.trader_to_signer.write(caller, signer); 
self.emit(NewBinding { trading_account: caller, signer: signer }); 


Recommendation(s): Consider checking if signer is not a zero address. 
Status: Fixed 


Update from the client: Addressed recommendation in pull request #25 in commit 94e206a70595e10428486449bca9b4432d9c5d16 


self.trader_to_signer.read(caller) == 0.try into().unwrap() 


6.11 [Best Practices] Function/variable/comment corrections 
File(s): src/* 

Description: The following is a list of functions, variables and comments that can be corrected: 
EcosystemTradeComponent.cairo 


— Function can_tranfer -> can. transfer ; 


Function trasfer_in -» transfer in; 


— Function trasfer. back -> transfer back ; 
— Assert message in apply. fixed. fees, MOSMATCH -> MISMATCH ; 


Recommendation(s): Consider implementing the corrections mentioned above. 
Status: Fixed 
Update from the client: Addressed in pull request #25 in commit de4853abe8e3ff9a6d75ca3b38db20af757b9f6d 
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ММ-02: 


6.12 [Best Practices] Redundant checking іп the function do maker checks 


File(s): src/Order.cairo 


Description: The function do maker. checks applies redundant checking for full fill only. It asserts that the maker. order is not full - 
fill only. However, when the flag post. only = true, the function applies again the same checking. 


fn do maker, checks (maker, order:Order, maker fill info:OrderTradeInfo, nonce:u32,fee_recipient:ContractAddress)-> (u256, 
+ u256) { 
ЙУ sus 
assert!(!maker order.flags.full fill only, "WRONG. MAKER FLAG: maker. order can't be full fill only"); 
assert!(get block timestamp() < maker order.constraints.created at.into() + 
^ maker, order.constraints.duration valid.into(), "Maker order expire (j" 
^ maker. order.constraints.duration valid); 
if maker order.flags.post only ( 
// @audit Redundant checking for !maker order.flags.full fill only 
"4 at this point, maker order.flags.full fill only -- false (it was checked above in the function) 
assert!(!maker. order.flags.best level only && !maker order.flags.full fill only, "WRONG. MAKER FLAGS"); 


Recommendation(s): Consider removing the redundant checking. 
Status: Fixed 
Update from the client: Addressed in pull request #25 in commit de4853abe8e3ff9a6d75ca3b38db20af 757b9f6d. 
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7 Documentation Evaluation 


Software documentation refers to the written or visual information that describes the functionality, architecture, design, and implementation 
of software. It provides a comprehensive overview of the software system and helps users, developers, and stakeholders understand how 
the software works, how to use it, and how to maintain it. Software documentation can take different forms, such as user manuals, system 
manuals, technical specifications, requirements documents, design documents, and code comments. Software documentation is critical 
in software development, enabling effective communication between developers, testers, users, and other stakeholders. It helps to ensure 
that everyone involved in the development process has a shared understanding of the software system and its functionality. Moreover, 
software documentation can improve software maintenance by providing a clear and complete understanding of the software system, 
making it easier for developers to maintain, modify, and update the software over time. Smart contracts can use various types of software 
documentation. Some of the most common types include: 


— Technical whitepaper: A technical whitepaper is a comprehensive document describing the smart contract's design and technical 
details. It includes information about the purpose of the contract, its architecture, its components, and how they interact with each 
other; 


— User manual: A user manual is a document that provides information about how to use the smart contract. It includes step-by-step 
instructions on how to perform various tasks and explains the different features and functionalities of the contract; 


— Code documentation: Code documentation is a document that provides details about the code of the smart contract. It includes 
information about the functions, variables, and classes used in the code, as well as explanations of how they work; 


— API documentation: API documentation is a document that provides information about the API (Application Programming Interface) 
of the smart contract. It includes details about the methods, parameters, and responses that can be used to interact with the 
contract; 


— Testing documentation: Testing documentation is a document that provides information about how the smart contract was tested. 
It includes details about the test cases that were used, the results of the tests, and any issues that were identified during testing; 


— Audit documentation: Audit documentation includes reports, notes, and other materials related to the security audit of the smart 
contract. This type of documentation is critical in ensuring that the smart contract is secure and free from vulnerabilities. 


These types of documentation are essential for smart contract development and maintenance. They help ensure that the contract is 
properly designed, implemented, and tested, and they provide a reference for developers who need to modify or maintain the contract in 
the future. 


Remarks about the LayerAkira Protocol documentation 


The documentation for LayerAkira is available on LayerAkira gitbook. It consists of sections with: 
General overview of the system. 


Technical Overview to specify fee types, exchange flow, trading pipeline and accounts, ecosystem book, router book, and 
routers. 


Trade section explaining details about the fees, order, deposit, and withdrawal. 


Several examples to illustrate the expected behavior for the main features. 


The information in the documentation is concise and technical, with well-written explanations. Code comments have a rea- 
sonable quality, with descriptions for the main structs. During the audit, the LayerAkira Team had effective communication. 
They were available for meetings to answer questions, explain further, and discuss the detected issues. In addition, they were 
consistently accessible, ensuring that our team could seek and receive timely clarifications and support as needed. 
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8 Test Suite Evaluation 


8.1 Contracts Compilation 


$ scarb --version; snforge --version 

scarb 2.6.3 (e6f921dfd 2024-03-13) 

cairo: 2.6.3 (https://crates.io/crates/cairo-lang-compiler/2.6.3) 
sierra: 1.5.0 

snforge 0.23.0 


$ scarb build 
Compiling kurosawa_akira v0.1.0 (/home/dev/dev/nm/synnax/gauss/NM-0237/report/kurosawa. akira/Scarb.toml) 
warn: Unused variable. Consider ignoring by prefixing with ^.^. (occurred four times, output omitted) 


Finished release target(s) in 10 seconds 


8.2 Tests Output 


$ snforge test 


Collected 39 test(s) from kurosawa akira package 
Running 39 test(s) from src/ 


[PASS] tests deposit and withdrawal. and, nonce: : dd 

PASS] tests router, trade::test cant execute with not registered router 

PASS] tests ecosystem trade::test succ match single sell taker trade full 

PASS] tests. quote. qty. ecosystem trade 01::test double qty. SELL maker. 05, double 

PASS] tests. quote. qty. ecosystem trade 01::test double. qty. BUY maker. 01. match. quote qty 

PASS] tests ecosystem trade::test succ match single buy. taker, trade full 

PASS] tests. quote. qty. ecosystem trade 02::test quote qty. only. base 

PASS] tests quote qty. ecosystem trade 02::test quote qty. only. quote 

PASS] tests quote qty. router, trade. 02::test, quote qty. both. 02 

PASS] tests deposit. and withdrawal. and nonce::test increase nonce 

PASS] tests. quote. qty. ecosystem trade 01::test double qty. SELL maker. 02, match, quote. qty 

PASS] tests. deposit. and withdrawal. and, nonce: :test withdraw eth direct. no. delayed by exchange 
PASS] tests ecosystem trade::test succ match single buy. taker, trade full router 

PASS] tests ecosystem trade::test succ match single sell taker. trade. full router 

PASS] tests. quote. qty. ecosystem trade 01::test double qty. SELL maker. 01 

PASS] tests ecosystem trade::test double qty. SELL maker, 01, oracle qty 

PASS] tests deposit, and withdrawal, and nonce::test eth deposit 
PASS] tests router trade::test execute with, buy. taker, succ 
PASS] tests. quote. qty. ecosystem trade 01::test double qty. SELL maker. 04. double 

PASS] tests deposit. and withdrawal. and, nonce::test withdraw eth direct immediate 

PASS] tests deposit. and withdrawal, and. nonce::test withdraw eth indirect twice 

PASS] tests. deposit and withdrawal. and. nonce::test withdraw eth direct delayed 

PASS] tests router, trade: :test execute with. buy. taker, succ. spent. side. fee for both parties 

PASS] tests. deposit. and withdrawal. and nonce::test withdraw eth indirect 

PASS] tests. quote. qty. router, trade 01::test roter trade double qty. semantic, SELL maker, 02 match, quote. qty 
PASS] tests quote gty. router, trade 01::test roter trade double qty semantic SELL maker, 03. match. base qty 
PASS] tests. quote. qty. router, trade. 02::test, quote qty. only. quote 

PASS] tests. quote qty. router, trade 01::test roter trade double qty. semantic, BUY maker. 01 

PASS] tests quote qty ecosystem trade 02::test quote qty. both, 02 

PASS] tests. quote qty. router, trade 01::test roter trade double qty. semantic, BUY, maker. 02. match. quote qty 
PASS] tests. quote qty. router, trade 01::test roter trade double qty. semantic, BUY maker, 03, match. base. qty 
PASS] tests quote qty router, trade 01::test roter trade double. qty. semantic, SELL maker, 01 

PASS] tests. router, trade: :test, punish router 

PASS] tests deposit and withdrawal. and, nonce::test withdraw eth direct delayed cant apply. twice 

PASS] tests. quote. qty. router, trade. 02::test, quote qty. both 

PASS] tests. quote. qty. ecosystem trade 01::test double qty. SELL maker, 03, match. base qty 

PASS] tests. quote. qty. router, trade. 02::test, quote. qty. only base 

PASS] tests. router. trade::test execute with sell taker. succ 

PASS] tests. quote. qty. ecosystem trade 02::test quote qty both 


Tests: 39 passed, 0 failed, 0 skipped, 0 ignored, 0 filtered out 
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9 About Nethermind 


Nethermind is a Blockchain Research and Software Engineering company. Our work touches every part of the web3 ecosystem - from 
layer 1 and layer 2 engineering, cryptography research, and security to application-layer protocol development. We offer strategic support 
to our institutional and enterprise partners across the blockchain, digital assets, and DeFi sectors, guiding them through all stages of the 
research and development process, from initial concepts to successful implementation. 


We offer security audits of projects built on EVM-compatible chains and Starknet. We are active builders of the Starknet ecosystem, 
delivering a node implementation, a block explorer, a Solidity-to-Cairo transpiler, and formal verification tooling. Nethermind also provides 
strategic support to our institutional and enterprise partners in blockchain, digital assets, and decentralized finance (DeFi). In the next 
paragraphs, we introduce the company in more detail. 


Blockchain Security: At Nethermind, we believe security is vital to the health and longevity of the entire Web3 ecosystem. We pro- 
vide security services related to Smart Contract Audits, Formal Verification, and Real-Time Monitoring. Our Security Team comprises 
blockchain security experts in each field, often collaborating to produce comprehensive and robust security solutions. The team has a 
strong academic background, can apply state-of-the-art techniques, and is experienced in analyzing cutting-edge Solidity and Cairo smart 
contracts, such as ArgentX and StarkGate (the bridge connecting Ethereum and StarkNet). Most team members hold a Ph.D. degree and 
actively participate in the research community, accounting for 240+ articles published and 1,4504 citations in Google Scholar. The security 
team adopts customer-oriented and interactive processes where clients are involved in all stages of the work. 


Blockchain Core Development: Our core engineering team, consisting of over 20 developers, maintains, improves, and upgrades our 
flagship product - the Nethermind Ethereum Execution Client. The client has been successfully operating for several years, supporting both 
the Ethereum Mainnet and its testnets, and now accounts for nearly a quarter of all synced Mainnet nodes. Our unwavering commitment 
to Ethereum's growth and stability extends to sidechains and layer 2 solutions. Notably, we were the sole execution layer client to facilitate 
Gnosis Chain's Merge, transitioning from Aura to Proof of Stake (PoS), and we are actively developing a full-node client to bolster Starknet's 
decentralization efforts. Our core team equips partners with tools for seamless node set-up, using generated docker-compose scripts 
tailored to their chosen execution client and preferred configurations for various network types. 


DevOps and Infrastructure Management: Our infrastructure team ensures our partners' systems operate securely, reliably, and effi- 
ciently. We provide infrastructure design, deployment, monitoring, maintenance, and troubleshooting support, allowing you to focus on 
your core business operations. Boasting extensive expertise in Blockchain as a Service, private blockchain implementations, and node 
management, our infrastructure and DevOps engineers are proficient with major cloud solution providers and can host applications in- 
house or on clients' premises. Our global in-house SRE teams offer 24/7 monitoring and alerts for both infrastructure and application 
levels. We manage over 5,000 public and private validators and maintain nodes on major public blockchains such as Polygon, Gnosis, 
Solana, Cosmos, Near, Avalanche, Polkadot, Aptos, and StarkWare L2. Sedge is an open-source tool developed by our infrastructure 
experts, designed to simplify the complex process of setting up a proof-of-stake (PoS) network or chain validator. Sedge generates docker- 
compose scripts for the entire validator set-up based on the chosen client, making the process easier and quicker while following best 
practices to avoid downtime and being slashed. 


Cryptography Research: At Nethermind, our Cryptography Research team is dedicated to continuous internal research while fostering 
close collaboration with external partners. The team has expertise across a wide range of domains, including cryptography protocols, 
consensus design, decentralized identity, verifiable credentials, Sybil resistance, oracles, and credentials, distributed validator technology 
(DVT), and Zero-knowledge proofs. This diverse skill set, combined with strong collaboration between our engineering teams, enables us 
to deliver cutting-edge solutions to our partners and clients. 


Smart Contract Development & DeFi Research: Our smart contract development and DeFi research team comprises 40+ world-class 
engineers who collaborate closely with partners to identify needs and work on value-adding projects. The team specializes in Solidity 
and Cairo development, architecture design, and DeFi solutions, including DEXs, AMMs, structured products, derivatives, and money 
market protocols, as well as ERC20, 721, and 1155 token design. Our research and data analytics focuses on three key areas: technical 
due diligence, market research, and DeFi research. Utilizing a data-driven approach, we offer in-depth insights and outlooks on various 
industry themes. 


Our suite of L2 tooling: Warp is Starknet's approach to EVM compatibility. It allows developers to take their Solidity smart contracts 
and transpile them to Cairo, Starknet's smart contract language. In the short time since its inception, the project has accomplished many 
achievements, including successfully transpiling Uniswap v3 onto Starknet using Warp. 


— Voyager is a user-friendly Starknet block explorer that offers comprehensive insights into the Starknet network. With its intuitive 
interface and powerful features, Voyager allows users to easily search for and examine transactions, addresses, and contract 
details. As an essential tool for navigating the Starknet ecosystem, Voyager is the go-to solution for users seeking in-depth 
information and analysis; 


— Horus is an open-source formal verification tool for StarkNet smart contracts. It simplifies the process of formally verifying Starknet 
smart contracts, allowing developers to express various assertions about the behavior of their code using a simple assertion 
language; 


— Juno is а full-node client implementation for Starknet, drawing on the expertise gained from developing the Nethermind Client. 
Written in Golang and open-sourced from the outset, Juno verifies the validity of the data received from Starknet by comparing it to 
proofs retrieved from Ethereum, thus maintaining the integrity and security of the entire ecosystem. 


Learn more about us at nethermind.io. 
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General Advisory to Clients 


As auditors, we recommend that any changes or updates made to the audited codebase undergo a re-audit or security review to address 
potential vulnerabilities or risks introduced by the modifications. By conducting a re-audit or security review of the modified codebase, 
you can significantly enhance the overall security of your system and reduce the likelihood of exploitation. However, we do not possess 
the authority or right to impose obligations or restrictions on our clients regarding codebase updates, modifications, or subsequent audits. 
Accordingly, the decision to seek a re-audit or security review lies solely with you. 


Disclaimer 


This report is based on the scope of materials and documentation provided by you to Nethermind in order that Nethermind could conduct 
the security review outlined in 1. Executive Summary and 2. Audited Files. The results set out in this report may not be complete nor 
inclusive of all vulnerabilities. Nethermind has provided the review and this report on an as-is, where-is, and as-available basis. You agree 
that your access and/or use, including but not limited to any associated services, products, protocols, platforms, content, and materials, 
will be at your sole risk. Blockchain technology remains under development and is subject to unknown risks and flaws. The review does 
not extend to the compiler layer, or any other areas beyond the programming language, or other programming aspects that could present 
security risks. This report does not indicate the endorsement of any particular project or team, nor guarantee its security. No third party 
should rely on this report in any way, including for the purpose of making any decisions to buy or sell a product, service or any other asset. 
To the fullest extent permitted by law, Nethermind disclaims any liability in connection with this report, its content, and any related services 
and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, 
and non-infringement. Nethermind does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised 
or offered by a third party through the product, any open source or third-party software, code, libraries, materials, or information linked to, 
called by, referenced by or accessible through the report, its content, and the related services and products, any hyperlinked websites, 
any websites or mobile applications appearing on any advertising, and Nethermind will not be a party to or in any way be responsible for 
monitoring any transaction between you and any third-party providers of products or services. As with the purchase or use of a product 
or service through any medium or in any environment, you should use your best judgment and exercise caution where appropriate. 
FOR AVOIDANCE OF DOUBT, THE REPORT, ITS CONTENT, ACCESS, AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED 
SERVICES OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, INVESTMENT, TAX, 
LEGAL, REGULATORY, OR OTHER ADVICE. 
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